Skip to main content

TenantSchemaAdminPanel

TenantSchemaAdminPanel is the LCARS Platform Ops surface for Valkyr ADMIN inspection of physically isolated tenant schemas.

It lives at:

web/typescript/valkyr_labs_com/src/components/Dashboard/components/TenantSchemaAdminPanel.tsx

Component Contract​

The panel imports generated ThorAPI model types:

import type { TenantSchemaRegistry } from "@thorapi/model/TenantSchemaRegistry";
import type { TenantSchemaAccessAudit } from "@thorapi/model/TenantSchemaAccessAudit";
import type { TenantSchemaOperation } from "@thorapi/model/TenantSchemaOperation";

The panel does not create local replacement model interfaces for ThorAPI-owned records. Local response types are limited to custom controller response records that are not generated model objects, such as tenant schema health and allowlisted object read responses.

Endpoint Contract​

All admin actions go through the lowercase custom controller:

GET  /v1/tenant-schemas
GET  /v1/tenant-schemas/{id}/health
POST /v1/tenant-schemas/{id}/validate
GET  /v1/tenant-schemas/{id}/audit
GET  /v1/tenant-schemas/{id}/objects/{objectType}
GET  /v1/tenant-schemas/{id}/objects/{objectType}/{objectId}
GET  /v1/schema-evolution/preview
POST /v1/schema-evolution/reconcile

The panel calls those endpoints with authJsonFetch and skipOrganizationHeaders: true because the backend controller resolves the registry, schema, and audit context itself. It does not use the generic DataWorkbook to browse customer schema data or generated schema reconciliation ledger rows.

UX Behavior​

  • Requires an operational reason or ticket before any request is enabled.
  • Mirrors the backend tenant-schema admin guard: reasons shorter than eight characters are rejected before schema inspection or audit writes.
  • Loads registry rows into the Platform Ops tenant schema table.
  • Lets an admin run health checks against the selected registry.
  • Shows active ThorAPI bundle name, version, checksum, generated time, and status returned by the health endpoint.
  • Shows manifest-derived bundle posture counts for total models, app_private models, shared models, external references, and declared shared relationship contracts without exposing the raw manifest JSON.
  • Shows the generated application id and active application data-plane binding id for each active bundle when the health endpoint reports them.
  • Shows non-secret write-plane details from the health endpoint: active data-plane status, mode, schema/database placement, database host/region, and active deployment id.
  • Warns when an active bundle reports managed app_database placement with a database name that does not match the server-derived appdb_<organization_uuid_without_dashes>_<application_id_prefix> contract.
  • Shows manifest-backed expected tables returned by the health endpoint.
  • Lets an admin validate the selected schema through an audited operation.
  • Lets an admin inspect allowlisted tenant object rows or one record by id.
  • Enables app_database/BYOC object inspection only after backend health verifies the object table through a matching runtime admin datasource; until that verification succeeds, those objects stay visibly disabled as runtime datasource targets.
  • Lets an admin load recent audit rows for the selected registry.
  • Lets an admin preview ThorAPI-generated schema reconciliation changes, including the safe auto-apply/manual-review split.
  • Lets an admin trigger the lowercase reconciliation endpoint for allowlisted safe generated repairs while preserving the visible applied/skipped/review summary returned by the backend.

Security Boundary​

The browser never sends a schema name, table name, or SQL fragment for tenant object reads. It sends only a TenantSchemaRegistry id, an allowlisted object type or expected table name, and the required reason.

Schema reconciliation controls also avoid generated DataWorkbook routes. The browser can only call the ADMIN-only lowercase preview/reconcile endpoints; SQL planning, statement hashing, locking, ledger writes, and safe/manual classification remain backend responsibilities.

The backend remains responsible for:

  • resolving the physical schema from TenantSchemaRegistry
  • resolving object/table access from active TenantSchemaBundle manifests
  • exposing active TenantSchemaBundle summaries in the health response so operators can see which generated bundle controls the allowlist
  • exposing bounded active bundle model/scope/relationship-contract counts so operators can identify app-private/shared posture without raw manifest access
  • exposing only non-secret active ApplicationDataPlaneBinding placement evidence through the health response
  • verifying separate app-database/BYOC placements through TenantSchemaExecutionService before allowing object inspection, and failing closed when only the shared registry datasource is available
  • rejecting non-allowlisted object types
  • redacting sensitive columns
  • writing TenantSchemaAccessAudit rows for allowed, denied, and failed reads
  • denying generated SchemaEvolutionLedger routes while allowing internal generated repository/service usage for ledgered reconciliation

Tests​

Focused coverage lives at:

src/components/Dashboard/components/__tests__/TenantSchemaAdminPanel.test.tsx
src/components/Dashboard/__tests__/LcarsSidebar.test.tsx
src/components/Dashboard/__tests__/EnhancedSixDDashboard.workflowStudio.test.tsx

The tests verify reason gating, audited endpoint usage, active bundle application/data-plane evidence, manifest-derived bundle posture counts, managed app database naming warnings, validation request bodies, schema reconciliation preview/reconcile endpoint usage, runtime-database object buttons staying disabled until backend verification succeeds, Platform Ops navigation, and dashboard tab restoration.